Brand new to IPF! Just found it last week and my simple rdr seemed to work -
until today.
Scoured the FAQ, Archive, google and this great writeup:
http://www.obfuscation.org/ipf/ipf-howto.txt

I have a very simple one-liner ipnat.conf, on Solaris 10 using the ipf
provided by the OS.

I just want to redirect port 80 to 8443 to get around running jboss to start
on a priv port.

r...@dev # cat /etc/ipf/ipnat.conf
#!/sbin/ipnat -f -
rdr e1000g0 0.0.0.0/0 port 443 -> 0.0.0.0 port 8443

r...@dev # ipf -V
ipf: IP Filter: v4.1.9 (592)
Kernel: IP Filter: v4.1.9
 Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 1
Feature mask: 0x107

r...@dev # uname -a
SunOS dev 5.10 Generic_127112-02 i86pc i386 i86pc

It works, but under a very slight load, my Ext/javascript/Ajax client times
out on transactions - in fact, I can simulate the timeout by sending our XML
commands to a little servlet I wrote. Its not really load - its just how
long it takes for the server to respond - I think ipf is closing the socket.

If the transaction (Ajax POST to a servlet) on the jboss server (really,
tomcat) takes more than ~4 seconds, the browser/client just hangs - the
server reports all is well, has sent all the data to the client, no
exceptions, no "broken pipes" or anything network related. Any command sent
that takes less than this time works fine!

Plus, the SAME XML sent to 8443 works fine, using nat, they timeout or abort
or simply disappear. Again, all commands "work" to 8443 - if I substitute
443 in my url from the browser, which goes thru the nat/rdr in ipf, "long"
transactions disappear or timeout.

While I'm running my commands I run this simple loop in another putty

while true; do date; ipnat -l ; sleep 1; done

(the ipfstat command doesn't have stats on redirections, it appears)

and the sessions almost immediately disappear after they're serviced - I get
a few during a transaction from my client going to port 443 and in the next
loop (after a 1 second sleep), they're gone. Very quick. Too quick?

I'm steeped in tcp/udp and all the ndd(1M) timers - expected to see similar
to CLOSE_WAIT states, etc. but can't seem to find anything in ipf -T that
smells too low.

The only tunable I see that resembles something like a timeout on tcp is
fr_tcptimeout and it is set to 240, which appears to be 4 * MSL (downloaded
source) which is set to 60 - and I get mixed messages via google whether
this is ticks (2/sec) or seconds - if seconds, my 4 SECOND connection is
certainly under the 4 minute timer if 240 = seconds.

I looked in the source for fr_tcptimeout and note from a header file that it
appears to read-write - i.e., ipf doesn't have to down for it to change:

# define    CTLFLAG_OFF 0x00800000  /* IPFilter must be disabled */
# define    CTLFLAG_RWO (CTLFLAG_RW|CTLFLAG_OFF)
SYSCTL_IPF(_net_inet_ipf, OID_AUTO, fr_tcptimeout, CTLFLAG_RWO,
       &fr_tcptimeout, 0, "");

Can someone help?

I've also tried to simply change the setting fr_tcptimeout (assuming I
didn't know the units and it was something horrible like ms):

I tried

Using ipf(1M)
r...@dev # ipf -D
r...@dev # ipf -T fr_tcptimeout=3600
r...@dev # ipf -T fr_tcptimeout
fr_tcptimeout   min 0x1 max 0x7fffffff  current 3600
 r...@dev # ipf -E
r...@dev # ipf -T fr_tcptimeout
fr_tcptimeout   min 0x1 max 0x7fffffff  current 240 # reverts back!

Using SMF:
r...@dev # ipf -T fr_tcptimeout
fr_tcptimeout   min 0x1 max 0x7fffffff  current 240
r...@dev # svcadm disable ipfilter
r...@dev # ipf -T fr_tcptimeout=3600
r...@dev # svcadm enable ipfilter
r...@dev # ipf -T fr_tcptimeout
fr_tcptimeout   min 0x1 max 0x7fffffff  current 240

Using ipf or SMF I can tell the ipf service is down, as my aforementioned
loop starts spewing ioctl problems.

Using ADB:
r...@dev # echo "fr_tcptimeout/W 3600" | adb -w -k /dev/ksyms /dev/mem
physmem 1ff78c
adb: failed to dereference symbol: unknown symbol name

This makes we worried I don't have the version embedded in the kernel.

Next is to try system(4) - but I don't even believe I'm getting a timeout
from ipf! Folks were on the box so couldn't reboot then.

Thanks for any help!

Brian

Reply via email to